home *** CD-ROM | disk | FTP | other *** search
/ Software of the Month Club 2000 October / Software of the Month - Ultimate Collection Shareware 277.iso / pc / PROGRAMS / UTILITY / WINLINUX / DATA1.CAB / programs_-_usrdoc / SHADOW-1.{2A / HOWTO.{__ < prev    next >
Text File  |  1999-09-17  |  69KB  |  1,919 lines
  1. [ Note: the installation instructions in this document are somewhat
  2.   out of date - the package now uses GNU autoconf and is configured
  3.   just like most GNU packages: run ./configure then make.  --marekm ]
  4.  
  5.   Linux Shadow Password HOWTO
  6.   Michael H. Jackson, mhjack@tscnet.com
  7.   v1.3, 3 April 1996
  8.  
  9.   This document aims to describe how to obtain, install, and configure
  10.   the Linux password Shadow Suite. It also discusses obtaining, and
  11.   reinstalling other software and network daemons that require access to
  12.   user passwords.  This other software is not actually part of the
  13.   Shadow Suite, but these programs will need to be recompiled to support
  14.   the Shadow Suite.  This document also contains a programming example
  15.   for adding shadow support to a program.  Answers to some of the more
  16.   frequently asked questions are included near the end of this document.
  17.  
  18.   1.  Introduction.
  19.  
  20.   This is the Linux Shadow-Password-HOWTO.  This document describes why
  21.   and how to add shadow password support on a Linux system.  Some
  22.   examples of how to use some of the Shadow Suite's features is also
  23.   included.
  24.  
  25.   When installing the Shadow Suite and when using many of the utility
  26.   programs, you must be logged in as root.  When installing the Shadow
  27.   Suite you will be making changes to system software, and it is highly
  28.   recommended that you make backup copies of programs as indicated.  I
  29.   also recommend that you read and understand all the instructions
  30.   before you begin.
  31.  
  32.   1.1.  Changes from the previous release.
  33.  
  34.   Additions:
  35.           Added a sub-section on why you might not want to install shadow
  36.           Added a sub-section on updating the xdm program
  37.           Added a section on how to put Shadow Suite features to work
  38.           Added a section containing frequently asked questions
  39.  
  40.   Corrections/Updates:
  41.           Corrected html references on Sunsite
  42.           Corrected section on wu-ftp to reflect adding -lshadow to the Makefile
  43.           Corrected minor spelling and verbiage errors
  44.           Changed section on wu-ftpd to support ELF
  45.           Updated to reflect security problems in various login programs
  46.           Updated to recommend the Linux Shadow Suite by Marek Michalkiewicz
  47.  
  48.   1.2.  New versions of this document.
  49.  
  50.   The latest released version of this document can always be retrieved
  51.   by anonymous FTP from:
  52.  
  53.   sunsite.unc.edu
  54.  
  55.   /pub/Linux/docs/HOWTO/Shadow-Password-HOWTO
  56.  
  57.   or:
  58.  
  59.   /pub/Linux/docs/HOWTO/other-formats/Shadow-Password-HOWTO{-html.tar,ps,dvi}.gz
  60.  
  61.   or via the World Wide Web from the Linux Documentation Project Web
  62.   Server <http://sunsite.unc.edu/mdw/linux.html>, at page: Shadow-
  63.   Password-HOWTO <http://sunsite.unc.edu/linux/HOWTO/Shadow-Password-
  64.   HOWTO.html> or directly from me, <mhjack@tscnet.com>. It will also be
  65.   posted to the newsgroup: comp.os.linux.answers
  66.  
  67.   This document is now packaged with the Shadow-YYDDMM packages.
  68.  
  69.   1.3.  Feedback.
  70.  
  71.   Please send any comments, updates, or suggestions to me: Michael H.
  72.   Jackson <mhjack@tscnet.com>  The sooner I get feedback, the sooner I
  73.   can update and correct this document.  If you find any problems with
  74.   it, please mail me directly as I very rarely stay up-to-date on the
  75.   newsgroups.
  76.  
  77.   2.  Why shadow your passwd file?
  78.  
  79.   By default, most current Linux distributions do not contain the Shadow
  80.   Suite installed.  This includes Slackware 2.3, Slackware 3.0, and
  81.   other popular distributions.  One of the reasons for this is that the
  82.   copyright notices in the original Shadow Suite were not clear on
  83.   redistribution if a fee was charged.  Linux uses a GNU Copyright
  84.   (sometimes refereed to as a Copyleft) that allows people to package it
  85.   into a convenient package (like a CD-ROM distribution) and charge a
  86.   fee for it.
  87.  
  88.   The current maintainer of the Shadow Suite, Marek Michalkiewicz
  89.   <marekm@i17linuxb.ists.pwr.wroc.pl> received the source code from the
  90.   original author under a BSD style copyright that allowed
  91.   redistribution.   Now that the copyright issues are resolved, it is
  92.   expected that future distributions will contain password shadowing by
  93.   default.  Until then, you will need to install it yourself.
  94.  
  95.   If you installed your distribution from a CD-ROM, you may find that,
  96.   even though the distribution did not have the Shadow Suite installed,
  97.   some of the files you need to install the Shadow Suite may be on the
  98.   CD-ROM.
  99.  
  100.   However, Shadow Suite versions 3.3.1, 3.3.1-2, and shadow-mk all have
  101.   security problems with their login program and several other suid root
  102.   programs that came with them, and should no longer be used.
  103.  
  104.   All of the necessary files may be obtained via anonymous FTP or
  105.   through the World Wide Web.
  106.  
  107.   On a Linux system without the Shadow Suite installed, user information
  108.   including passwords is stored in the /etc/passwd file.  The password
  109.   is stored in an encrypted format.  If you ask a cryptography expert,
  110.   however, he or she will tell you that the password is actually in an
  111.   encoded rather than encrypted format because when using crypt(3), the
  112.   text is set to null and the password is the key.  Therefore, from here
  113.   on, I will use the term encoded in this document.
  114.  
  115.   The algorithm used to encode the password field is technically
  116.   referred to as a one way hash function.  This is an algorithm that is
  117.   easy to compute in one direction, but very difficult to calculate in
  118.   the reverse direction.  More about the actual algorithm used can be
  119.   found in section 2.4 or your crypt(3) manual page.
  120.  
  121.   When a user picks or is assigned a password, it is encoded with a
  122.   randomly generated value called the salt.  This means that any
  123.   particular password could be stored in 4096 different ways.  The salt
  124.   value is then stored with the encoded password.
  125.  
  126.   When a user logs in and supplies a password, the salt is first
  127.   retrieved from the stored encoded password.  Then the supplied
  128.   password is encoded with the salt value, and then compared with the
  129.   encoded password.  If there is a match, then the user is
  130.   authenticated.
  131.  
  132.   It is computationally difficult (but not impossible) to take a
  133.   randomly encoded password and recover the original password.  However,
  134.   on any system with more than just a few users, at least some of the
  135.   passwords will be common words (or simple variations of common words).
  136.  
  137.   System crackers know all this, and will simply encrypt a dictionary of
  138.   words and common passwords using all possible 4096 salt values.  Then
  139.   they will compare the encoded passwords in your /etc/passwd file with
  140.   their database.  Once they have found a match, they have the password
  141.   for another account.  This is referred to as a dictionary attack, and
  142.   is one of the most common methods for gaining or expanding
  143.   unauthorized access to a system.
  144.  
  145.   If you think about it, an 8 character password encodes to 4096 * 13
  146.   character strings.  So a dictionary of say 400,000 common words,
  147.   names, passwords, and simple variations would easily fit on a 4GB hard
  148.   drive.  The attacker need only sort them, and then check for matches.
  149.   Since a 4GB hard drive can be had for under $1000.00, this is well
  150.   within the means of most system crackers.
  151.  
  152.   Also, if a cracker obtains your /etc/passwd file first, they only need
  153.   to encode the dictionary with the salt values actually contained in
  154.   your /etc/passwd file.  This method is usable by your average teenager
  155.   with a couple of hundred spare Megabytes and a 486 class computer.
  156.  
  157.   Even without lots of drive space, utilities like crack(1) can usually
  158.   break at least a couple of passwords on a system with enough users
  159.   (assuming the users of the system are allowed to pick their own
  160.   passwords).
  161.  
  162.   The /etc/passwd file also contains information like user ID's and
  163.   group ID's that are used by many system programs.  Therefore, the
  164.   /etc/passwd file must remain world readable.  If you were to change
  165.   the /etc/passwd file so that nobody can read it, the first thing that
  166.   you would notice is that the ls -l command now displays user ID's
  167.   instead of names!
  168.  
  169.   The Shadow Suite solves the problem by relocating the passwords to
  170.   another file (usually /etc/shadow).  The /etc/shadow file is set so
  171.   that it cannot be read by just anyone.  Only root will be able to read
  172.   and write to the /etc/shadow file.  Some programs (like xlock) don't
  173.   need to be able to change passwords, they only need to be able to
  174.   verify them.  These programs can either be run suid root or you can
  175.   set up a group shadow that is allowed read only access to the
  176.   /etc/shadow file.  Then the program can be run sgid shadow.
  177.  
  178.   By moving the passwords to the /etc/shadow file, we are effectively
  179.   keeping the attacker from having access to the encoded passwords with
  180.   which to perform a dictionary attack.
  181.  
  182.   Additionally, the Shadow Suite adds lots of other nice features:
  183.  
  184.   ╖  A configuration file to set login defaults (/etc/login.defs)
  185.  
  186.   ╖  Utilities for adding, modifying, and deleting user accounts and
  187.      groups
  188.  
  189.   ╖  Password aging and expiration
  190.  
  191.   ╖  Account expiration and locking
  192.  
  193.   ╖  Shadowed group passwords (optional)
  194.  
  195.   ╖  Double length passwords (16 character passwords) NOT RECOMMENDED
  196.  
  197.   ╖  Better control over user's password selection
  198.  
  199.   ╖  Dial-up passwords
  200.  
  201.   ╖  Secondary authentication programs NOT RECOMMENDED
  202.  
  203.   Installing the Shadow Suite contributes toward a more secure system,
  204.   but there are many other things that can also be done to improve the
  205.   security of a Linux system, and there will eventually be a series of
  206.   Linux Security HOWTO's that will discuss other security measures and
  207.   related issues.
  208.  
  209.   For current information on other Linux security issues, including
  210.   warnings on known vulnerabilities see the Linux Security home page.
  211.   <http://bach.cis.temple.edu/linux/linux-security/>
  212.  
  213.   2.1.  Why you might NOT want to shadow your passwd file.
  214.  
  215.   There are a few circumstances and configurations in which installing
  216.   the Shadow Suite would NOT be a good idea:
  217.  
  218.   ╖  The machine does not contain user accounts.
  219.  
  220.   ╖  Your machine is running on a LAN and is using NIS (Network
  221.      Information Services) to get or supply user names and passwords to
  222.      other machines on the network.  (This can actually be done, but is
  223.      beyond the scope of this document, and really won't increase
  224.      security much anyway)
  225.  
  226.   ╖  Your machine is being used by terminal servers to verify users via
  227.      NFS (Network File System), NIS, or some other method.
  228.  
  229.   ╖  Your machine runs other software that validates users, and there is
  230.      no shadow version available, and you don't have the source code.
  231.  
  232.   2.2.  Format of the /etc/passwd file
  233.  
  234.   A non-shadowed /etc/passwd file has the following format:
  235.  
  236.        username:passwd:UID:GID:full_name:directory:shell
  237.  
  238.   Where:
  239.  
  240.      username
  241.         The user (login) name
  242.  
  243.      passwd
  244.         The encoded password
  245.  
  246.      UID
  247.         Numerical user ID
  248.  
  249.      GID
  250.         Numerical default group ID
  251.  
  252.      full_name
  253.         The user's full name - Actually this field is called the GECOS
  254.         (General Electric Comprehensive Operating System) field and can
  255.         store information other than just the full name.  The Shadow
  256.         commands and manual pages refer to this field as the comment
  257.         field.
  258.  
  259.      directory
  260.         User's home directory (Full pathname)
  261.  
  262.      shell
  263.         User's login shell (Full Pathname)
  264.  
  265.   For example:
  266.  
  267.        username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
  268.  
  269.   Where Np is the salt and ge08pfz4wuk is the encoded password.  The
  270.   encoded salt/password could just as easily have been kbeMVnZM0oL7I and
  271.   the two are exactly the same password.  There are 4096 possible encod¡
  272.   ings for the same password.  (The example password in this case is
  273.   'password', a really bad password).
  274.  
  275.   Once the shadow suite is installed, the /etc/passwd file would instead
  276.   contain:
  277.  
  278.        username:x:503:100:Full Name:/home/username:/bin/sh
  279.  
  280.   The x in the second field in this case is now just a place holder.
  281.   The format of the /etc/passwd file really didn't change, it just no
  282.   longer contains the encoded password.  This means that any program
  283.   that reads the /etc/passwd file but does not actually need to verify
  284.   passwords will still operate correctly.
  285.  
  286.   The passwords are now relocated to the shadow file (usually
  287.   /etc/shadow file).
  288.  
  289.   2.3.  Format of the shadow file
  290.  
  291.   The /etc/shadow file contains the following information:
  292.  
  293.        username:passwd:last:may:must:warn:expire:disable:reserved
  294.  
  295.   Where:
  296.  
  297.      username
  298.         The User Name
  299.  
  300.      passwd
  301.         The Encoded password
  302.      last
  303.         Days since Jan 1, 1970 that password was last changed
  304.  
  305.      may
  306.         Days before password may be changed
  307.  
  308.      must
  309.         Days after which password must be changed
  310.  
  311.      warn
  312.         Days before password is to expire that user is warned
  313.  
  314.      expire
  315.         Days after password expires that account is disabled
  316.  
  317.      disable
  318.         Days since Jan 1, 1970 that account is disabled
  319.  
  320.      reserved
  321.         A reserved field
  322.  
  323.   The previous example might then be:
  324.  
  325.        username:Npge08pfz4wuk:9479:0:10000::::
  326.  
  327.   2.4.  Review of crypt(3).
  328.  
  329.   From the crypt(3) manual page:
  330.  
  331.   "crypt is the password encryption function.  It is based on the Data
  332.   Encryption Standard algorithm with variations intended (among other
  333.   things) to discourage use of hardware implementations of a key search.
  334.  
  335.   The key is a user's typed password.  The encoded string is all NULLs
  336.  
  337.   The salt is a two-character string chosen from the set a-zA-Z0-9./.
  338.   This string is used to perturb the algorithm in one of 4096 different
  339.   ways.
  340.  
  341.   By taking the lowest 7 bits of each character of the key, a 56-bit key
  342.   is obtained.  This 56-bit key is used to encrypt repeatedly a constant
  343.   string (usually a string consisting of all zeros).  The returned value
  344.   points to the encrypted password, a series of 13 printable ASCII
  345.   characters (the first two characters represent the salt itself).  The
  346.   return value points to static data whose content is overwritten by
  347.   each call.
  348.  
  349.   Warning: The key space consists of 2**56 equal 7.2e16 possible values.
  350.   Exhaustive searches of this key space are possible using massively
  351.   parallel computers.  Software, such as crack(1), is available which
  352.   will search the portion of this key space that is generally used by
  353.   humans for passwords.  Hence, password selection should, at minimum,
  354.   avoid common words and names.  The use of a passwd(1) program that
  355.   checks for crackable passwords during the selection process is
  356.   recommended.
  357.  
  358.   The DES algorithm itself has a few quirks which make the use of the
  359.   crypt(3) interface a very poor choice for anything other than password
  360.   authentication.  If you are planning on using the crypt(3) interface
  361.   for a cryptography project, don't do it: get a good book on encryption
  362.   and one of the widely available DES libraries."
  363.  
  364.   Most Shadow Suites contain code for doubling the length of the
  365.   password to 16 characters.  Experts in des recommend against this, as
  366.   the encoding is simply applied first to the left half and then to the
  367.   right half of the longer password.  Because of the way crypt works,
  368.   this may make for a less secure encoded password then if double length
  369.   passwords were not used in the first place.  Additionally, it is less
  370.   likely that a user will be able to remember a 16 character password.
  371.  
  372.   There is development work under way that would allow the
  373.   authentication algorithm to be replaced with something more secure and
  374.   with support for longer passwords (specifically the MD5 algorithm) and
  375.   retain compatibility with the crypt method.
  376.  
  377.   If you are looking for a good book on encryption, I recommend:
  378.  
  379.           "Applied Cryptography: Protocols, Algorithms, and Source Code in C"
  380.           by Bruce Schneier <schneier@chinet.com>
  381.           ISBN: 0-471-59756-2
  382.  
  383.   3.  Getting the Shadow Suite.
  384.  
  385.   3.1.  History of the Shadow Suite for Linux
  386.  
  387.   DO NOT USE THE PACKAGES IN THIS SECTION, THEY HAVE SECURITY PROBLEMS
  388.  
  389.   The original Shadow Suite was written by Julianne F. Haugh
  390.  
  391.   There are several versions that have been used on Linux systems:
  392.  
  393.   ╖  shadow-3.3.1 is the original.
  394.  
  395.   ╖  shadow-3.3.1-2 is Linux specific patch made by Florian La Roche
  396.      <flla@stud.uni-sb.de> and contains some further enhancements.
  397.  
  398.   ╖  shadow-mk was specifically packaged for Linux.
  399.  
  400.   The shadow-mk package contains the shadow-3.3.1 package distributed by
  401.   Julianne F. Haugh with the shadow-3.3.1-2 patch installed, a few fixes
  402.   made by Mohan Kokal <magnus@texas.net> that make installation a lot
  403.   easier, a patch by Joseph R.M. Zbiciak for login1.c (login.secure)
  404.   that eliminates the -f, -h security holes in /bin/login, and some
  405.   other miscellaneous patches.
  406.  
  407.   The shadow.mk package was the previously recommended package, but
  408.   should be replaced due to a security problem with the login program.
  409.  
  410.   There are security problems with Shadow versions 3.3.1, 3.3.1-2, and
  411.   shadow-mk involving the login program.  This login bug involves not
  412.   checking the length of a login name.  This causes the buffer to
  413.   overflow causing crashes or worse.  It has been rumored that this
  414.   buffer overflow can allow someone with an account on the system to use
  415.   this bug and the shared libraries to gain root access.  I won't
  416.   discuss exactly how this is possible because there are a lot of Linux
  417.   systems that are affected, but systems with these Shadow Suites
  418.   installed, and most pre-ELF distributions without the Shadow Suite are
  419.   vulnerable!
  420.  
  421.   For more information on this and other Linux security issues, see the
  422.   Linux Security home page (Shared Libraries and login Program
  423.   Vulnerability) <http://bach.cis.temple.edu/linux/linux-security/Linux-
  424.   Security-FAQ/Linux-telnetd.html>
  425.  
  426.   3.2.  Where to get the Shadow Suite.
  427.  
  428.   The only recommended Shadow Suite is still in BETA testing, however
  429.   the latest versions are safe in a production environment and don't
  430.   contain a vulnerable login program.
  431.  
  432.   The package uses the following naming convention:
  433.  
  434.        shadow-YYMMDD.tar.gz
  435.  
  436.   where YYMMDD is the issue date of the Suite.
  437.  
  438.   This version will eventually be Version 3.3.3 when it is released from
  439.   Beta testing, and is maintained by Marek Michalkiewicz
  440.   <marekm@i17linuxb.ists.pwr.wroc.pl>.  It's available as: shadow-
  441.   current.tar.gz
  442.   <ftp://i17linuxb.ists.pwr.wroc.pl/pub/linux/shadow/shadow-
  443.   current.tar.gz>.
  444.  
  445.   The following mirror sites have also been established:
  446.  
  447.   ╖  ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz
  448.  
  449.   ╖  ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz
  450.  
  451.   ╖  ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz
  452.  
  453.   ╖  ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz
  454.  
  455.   You should use the currently available version.
  456.  
  457.   You should NOT use a version older than shadow-960129 as they also
  458.   have the login security problem discussed above.
  459.  
  460.   When this document refers to the Shadow Suite I am referring to the
  461.   this package.  It is assumed that this is the package that you are
  462.   using.
  463.  
  464.   For reference, I used shadow-960129 to make these installation
  465.   instructions.
  466.  
  467.   If you were previously using shadow-mk, you should upgrade to this
  468.   version and rebuild everything that you originally compiled.
  469.  
  470.   3.3.  What is included with the Shadow Suite.
  471.  
  472.   The Shadow Suite contains replacement programs for:
  473.  
  474.   su, login, passwd, newgrp, chfn, chsh, and id
  475.  
  476.   The package also contains the new programs:
  477.  
  478.   chage, newusers, dpasswd, gpasswd, useradd, userdel, usermod,
  479.   groupadd, groupdel, groupmod, groups, pwck, grpck, lastlog, pwconv,
  480.   and pwunconv
  481.  
  482.   Additionally, the library: libshadow.a is included for writing and/or
  483.   compiling programs that need to access user passwords.
  484.  
  485.   Also, manual pages for the programs are also included.
  486.  
  487.   There is also a configuration file for the login program which will be
  488.   installed as /etc/login.defs.
  489.  
  490.   4.  Compiling the programs.
  491.  
  492.   4.1.  Unpacking the archive.
  493.  
  494.   The first step after retrieving the package is unpacking it.  The
  495.   package is in the tar (tape archive) format and compressed using gzip,
  496.   so first move it to /usr/src, then type:
  497.  
  498.        tar -xzvf shadow-current.tar.gz
  499.  
  500.   This will unpack it into the directory: /usr/src/shadow-YYMMDD
  501.  
  502.   4.2.  Configuring with the config.h file
  503.  
  504.   The first thing that you need to do is to copy over the Makefile and
  505.   the config.h file:
  506.  
  507.        cd /usr/src/shadow-YYMMDD
  508.        cp Makefile.linux Makefile
  509.        cp config.h.linux config.h
  510.  
  511.   You should then take a look at the config.h file.  This file contains
  512.   definitions for some of the configuration options.  If you are using
  513.   the recommended package, I recommend that you disable group shadow
  514.   support for your first time around.
  515.  
  516.   By default shadowed group passwords are enabled.  To disable these
  517.   edit the config.h file, and change the #define SHADOWGRP to #undef
  518.   SHADOWGRP. I recommend that you disable them to start with, and then
  519.   if you really want group passwords and group administrators that you
  520.   enable it later and recompile.  If you leave it enabled, you must
  521.   create the file /etc/gshadow.
  522.  
  523.   Enabling the long passwords option is NOT recommended as discussed
  524.   above.
  525.  
  526.   Do NOT change the setting: #undef AUTOSHADOW
  527.  
  528.   The AUTOSHADOW option was originally designed so that programs that
  529.   were shadow ignorant would still function.  This sounds good in
  530.   theory, but does not work correctly.  If you enable this option, and
  531.   the program runs as root, it may call getpwnam() as root, and later
  532.   write the modified entry back to the /etc/passwd file (with the no-
  533.   longer-shadowed password).  Such programs include chfn and chsh.  (You
  534.   can't get around this by swapping real and effective uid before
  535.   calling getpwnam() because root may use chfn and chsh too.)
  536.  
  537.   The same warning is also valid if you are building libc, it has a
  538.   SHADOW_COMPAT option which does the same thing.  It should NOT be
  539.   used!  If you start getting encoded passwords back in your /etc/passwd
  540.   file, this is the problem.
  541.  
  542.   If you are using a libc version prior to 4.6.27, you will need to make
  543.   a couple more changes to config.h and the Makefile.  To config.h edit
  544.   and change:
  545.  
  546.        #define HAVE_BASENAME
  547.  
  548.   to:
  549.  
  550.        #undef HAVE_BASENAME
  551.  
  552.   And then in the Makefile, change:
  553.  
  554.        SOBJS = smain.o env.o entry.o susetup.o shell.o \
  555.                sub.o mail.o motd.o sulog.o age.o tz.o hushed.o
  556.  
  557.        SSRCS = smain.c env.c entry.c setup.c shell.c \
  558.                pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
  559.                tz.c hushed.c
  560.  
  561.        SOBJS = smain.o env.o entry.o susetup.o shell.o \
  562.                sub.o mail.o motd.o sulog.o age.o tz.o hushed.o basename.o
  563.  
  564.        SSRCS = smain.c env.c entry.c setup.c shell.c \
  565.                pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
  566.                tz.c hushed.c basename.c
  567.  
  568.   These changes add the code contained in basename.c which is contained
  569.   in libc 4.6.27 and later.
  570.  
  571.   4.3.  Making backup copies of your original programs.
  572.  
  573.   It would also be a good idea to track down and make backup copies of
  574.   the programs that the shadow suite will replace.  On a Slackware 3.0
  575.   system these are:
  576.  
  577.   ╖  /bin/su
  578.  
  579.   ╖  /bin/login
  580.  
  581.   ╖  /usr/bin/passwd
  582.  
  583.   ╖  /usr/bin/newgrp
  584.  
  585.   ╖  /usr/bin/chfn
  586.  
  587.   ╖  /usr/bin/chsh
  588.  
  589.   ╖  /usr/bin/id
  590.  
  591.   The BETA package has a save target in the Makefile, but it's commented
  592.   out because different distributions place the programs in different
  593.   places.
  594.  
  595.   You should also make a backup copy of your /etc/passwd file, but be
  596.   careful to name it something else if you place it in the same
  597.   directory so you don't overwrite the passwd command.
  598.  
  599.   4.4.  Running make
  600.  
  601.   You need to be logged as root to do most of the installation.
  602.  
  603.   Run make to compile the executables in the package:
  604.  
  605.        make all
  606.  
  607.   You may see the warning: rcsid defined but not used.  This is fine, it
  608.   just happens because the author is using a version control package.
  609.  
  610.   5.  Installing
  611.  
  612.   5.1.  Have a boot disk handy in case you break anything.
  613.  
  614.   If something goes terribly wrong, it would be handy to have a boot
  615.   disk.  If you have a boot/root combination from your installation,
  616.   that will work, otherwise see the Bootdisk-HOWTO
  617.   <http://sunsite.unc.edu/mdw/HOWTO/Bootdisk-HOWTO.html>, which
  618.   describes how to make a bootable disk.
  619.  
  620.   5.2.  Removing duplicate man pages
  621.  
  622.   You should also move the manual pages that are about to be replaced.
  623.   Even if you are brave enough install the Shadow Suite without making
  624.   backups, you will still want to remove the old manual pages.  The new
  625.   manual pages won't normally overwrite the old ones because the old
  626.   ones are probably compressed.
  627.  
  628.   You can use a combination of: man -aW command and locate command to
  629.   locate the manual pages that need to be (re)moved.  It's generally
  630.   easier to figure out which are the older pages before you run make
  631.   install.
  632.  
  633.   If you are using the Slackware 3.0 distribution, then the manual pages
  634.   you want to remove are:
  635.  
  636.   ╖  /usr/man/man1/chfn.1.gz
  637.  
  638.   ╖  /usr/man/man1/chsh.1.gz
  639.  
  640.   ╖  /usr/man/man1/id.1.gz
  641.  
  642.   ╖  /usr/man/man1/login.1.gz
  643.  
  644.   ╖  /usr/man/man1/passwd.1.gz
  645.  
  646.   ╖  /usr/man/man1/su.1.gz
  647.  
  648.   ╖  /usr/man/man5/passwd.5.gz
  649.  
  650.   There may also be man pages of the same name in the /var/man/cat[1-9]
  651.   subdirectories that should also be deleted.
  652.  
  653.   5.3.  Running make install
  654.  
  655.   You are now ready to type: (do this as root)
  656.  
  657.        make install
  658.  
  659.   This will install the new and replacement programs and fix-up the file
  660.   permissions.  It will also install the man pages.
  661.  
  662.   This also takes care of installing the Shadow Suite include files in
  663.   the correct places in /usr/include/shadow.
  664.  
  665.   Using the BETA package you must manually copy the file login.defs to
  666.   the /etc subdirectory and make sure that only root can make changes to
  667.   it.
  668.  
  669.        cp login.defs /etc
  670.        chmod 700 /etc/login.defs
  671.  
  672.   This file is the configuration file for the login program.  You should
  673.   review and make changes to this file for your particular system.  This
  674.   is where you decide which tty's root can login from, and set other
  675.   security policy settings (like password expiration defaults).
  676.  
  677.   5.4.  Running pwconv
  678.  
  679.   The next step is to run pwconv.  This must also be done as root, and
  680.   is best done from the /etc subdirectory:
  681.  
  682.        cd /etc
  683.        /usr/sbin/pwconv
  684.  
  685.   pwconv takes your /etc/passwd file and strips out the fields to create
  686.   two files: /etc/npasswd and /etc/nshadow.
  687.  
  688.   A pwunconv program is also provided if you need to make a normal
  689.   /etc/passwd file out of an /etc/passwd and /etc/shadow combination.
  690.  
  691.   5.5.  Renaming npasswd and nshadow
  692.  
  693.   Now that you have run pwconv you have created the files /etc/npasswd
  694.   and /etc/nshadow.  These need to be copied over to /etc/passwd and
  695.   /etc/shadow.  We also want to make a backup copy of the original
  696.   /etc/passwd file, and make sure only root can read it.  We'll put the
  697.   backup in root's home directory:
  698.  
  699.        cd /etc
  700.        cp passwd ~passwd
  701.        chmod 600 ~passwd
  702.        mv npasswd passwd
  703.        mv nshadow shadow
  704.  
  705.   You should also ensure that the file ownerships and permissions are
  706.   correct.  If you are going to be using X-Windows, the xlock and xdm
  707.   programs need to be able to read the shadow file (but not write it).
  708.  
  709.   There are two ways that this can be done.  You can set xlock to suid
  710.   root (xdm is usually run as root anyway).  Or you can make the shadow
  711.   file owned by root with a group of shadow, but before you do this,
  712.   make sure that you have a shadow group (look in /etc/group).  None of
  713.   the users on the system should actually be in the shadow group.
  714.  
  715.        chown root.root passwd
  716.        chown root.shadow shadow
  717.        chmod 0644 passwd
  718.        chmod 0640 shadow
  719.  
  720.   Your system now has the password file shadowed.  You should now pop
  721.   over to another virtual terminal and verify that you can login.
  722.  
  723.   Really, do this now!
  724.  
  725.   If you can't, then something is wrong!  To get back to a non-shadowed
  726.   state, do the following the following:
  727.  
  728.        cd /etc
  729.        cp ~passwd passwd
  730.        chmod 644 passwd
  731.  
  732.   You would then restore the files that you saved earlier to their
  733.   proper locations.
  734.  
  735.   6.  Other programs you may need to upgrade or patch
  736.  
  737.   Even though the shadow suite contains replacement programs for most
  738.   programs that need to access passwords, there are a few additional
  739.   programs on most systems that require access to passwords.
  740.  
  741.   If you are running a Debian Distribution (or even if you are not), you
  742.   can obtain Debian sources for the programs that need to be rebuild
  743.   from: ftp://ftp.debian.org/debian/stable/source/
  744.  
  745.   The remainder of this section discusses how to upgrade adduser,
  746.   wu_ftpd, ftpd, pop3d, xlock, xdm and sudo so that they support the
  747.   shadow suite.
  748.  
  749.   See the section ``Adding Shadow Support to a C program'' for a
  750.   discussion on how to put shadow support into any other program that
  751.   needs it (although the program must then be run SUID root or SGID
  752.   shadow to be able to actually access the shadow file).
  753.  
  754.   6.1.  Slackware adduser program
  755.  
  756.   Slackware distributions (and possibly some others) contain a
  757.   interactive program for adding users called /sbin/adduser.  A shadow
  758.   version of this program can be obtained from
  759.   ftp://sunsite.unc.edu/pub/Linux/
  760.   system/Admin/accounts/adduser.shadow-1.4.tar.gz.
  761.  
  762.   I would encourage you to use the programs that are supplied with the
  763.   Shadow Suite (useradd, usermod, and userdel) instead of the slackware
  764.   adduser program.  They take a little time to learn how to use, but
  765.   it's well worth the effort because you have much more control and they
  766.   perform proper file locking on the /etc/passwd and /etc/shadow file
  767.   (adduser doesn't).
  768.  
  769.   See the section on ``Putting the Shadow Suite to use'' for more
  770.   information.
  771.  
  772.   But if you gotta have it, here is what you do:
  773.  
  774.        tar -xzvf adduser.shadow-1.4.tar.gz
  775.        cd adduser
  776.        make clean
  777.        make adduser
  778.        chmod 700 adduser
  779.        cp adduser /sbin
  780.  
  781.   6.2.  The wu_ftpd Server
  782.  
  783.   Most Linux systems some with the wu_ftpd server.  If your distribution
  784.   does not come with shadow installed, then your wu_ftpd will not be
  785.   compiled for shadow.  wu_ftpd is launched from inetd/tcpd as a root
  786.   process.  If you are running an old wu_ftpd daemon, you will want to
  787.   upgrade it anyway because older ones had a bug that would allow the
  788.   root account to be compromised (For more info see the Linux security
  789.   home page <http://bach.cis.temple.edu/linux/linux-security/Linux-
  790.   Security-FAQ/Linux-wu.ftpd-2.4-Update.html>).
  791.  
  792.   Fortunately, you only need to get the source code and recompile it
  793.   with shadow enabled.
  794.  
  795.   If you are not running an ELF system, The wu_ftp server can be found
  796.   on Sunsite as wu-ftp-2.4-fixed.tar.gz
  797.   <ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/wu-
  798.   ftpd-2.4-fixed.tar.gz>
  799.  
  800.   Once you retrieve the server, put it in /usr/src, then type:
  801.  
  802.   cd /usr/src
  803.   tar -xzvf wu-ftpd-2.4-fixed.tar.gz
  804.   cd wu-ftpd-2.4-fixed
  805.   cp ./src/config/config.lnx.shadow ./src/config/config.lnx
  806.  
  807.   Then edit ./src/makefiles/Makefile.lnx, and change the line:
  808.  
  809.        LIBES    = -lbsd -support
  810.  
  811.   to:
  812.  
  813.        LIBES    = -lbsd -support -lshadow
  814.  
  815.   Now you are ready to run the build script and install:
  816.  
  817.        cd /usr/src/wu-ftpd-2.4-fixed
  818.        /usr/src/wu-ftp-2.4.fixed/build lnx
  819.        cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
  820.        cp ./bin/ftpd /usr/sbin/wu.ftpd
  821.  
  822.   This uses the Linux shadow configuration file, compiles and installs
  823.   the server.
  824.  
  825.   On my Slackware 2.3 system I also had to do the following before
  826.   running build:
  827.  
  828.        cd /usr/include/netinet
  829.        ln -s in_systm.h in_system.h
  830.        cd -
  831.  
  832.   Problems have been reported compiling this package under ELF systems,
  833.   but the Beta version of the next release works fine.  It can be found
  834.   as wu-ftp-2.4.2-beta-10.tar.gz
  835.   <ftp://tscnet.com/pub/linux/network/ftp/wu-ftpd-2.4.2-beta-10.tar.gz>
  836.  
  837.   Once you retrieve the server, put it in /usr/src, then type:
  838.  
  839.        cd /usr/src
  840.        tar -xzvf wu-ftpd-2.4.2-beta-9.tar.gz
  841.        cd wu-ftpd-beta-9
  842.        cd ./src/config
  843.  
  844.   Then edit config.lnx, and change:
  845.  
  846.        #undef SHADOW.PASSWORD
  847.  
  848.   to:
  849.  
  850.        #define SHADOW.PASSWORD
  851.  
  852.   Then,
  853.  
  854.        cd ../Makefiles
  855.  
  856.   and edit the file Makefile.lnx and change:
  857.  
  858.        LIBES = -lsupport -lbsd # -lshadow
  859.  
  860.   to:
  861.  
  862.        LIBES = -lsupport -lbsd -lshadow
  863.  
  864.   Then build and install:
  865.  
  866.        cd ..
  867.        build lnx
  868.        cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
  869.        cp ./bin/ftpd /usr/sbin/wu.ftpd
  870.  
  871.   Note that you should check your /etc/inetd.conf file to make sure that
  872.   this is where your wu.ftpd server really lives.  It has been reported
  873.   that some distributions place the server daemons in different places,
  874.   and then wu.ftpd in particular may be named something else.
  875.  
  876.   6.3.  Standard ftpd
  877.  
  878.   If you are running the standard ftpd server, I would recommend that
  879.   you upgrade to the wu_ftpd server.  Aside from the known bug discussed
  880.   above, it's generally thought to be more secure.
  881.  
  882.   If you insist on the standard one, or you need NIS support, Sunsite
  883.   has ftpd-shadow-nis.tgz
  884.   <ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/ftpd-
  885.   shadow-nis.tgz>
  886.  
  887.   6.4.  pop3d (Post Office Protocol 3)
  888.  
  889.   If you need to support the third Post Office Protocol (POP3), you will
  890.   need to recompile a pop3d program.  pop3d is normally run by
  891.   inetd/tcpd as root.
  892.  
  893.   There are two versions available from Sunsite:
  894.   pop3d-1.00.4.linux.shadow.tar.gz
  895.   <ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d-1.00.4.linux.shadow.tar.gz>
  896.   and pop3d+shadow+elf.tar.gz
  897.   <ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d+shadow+elf.tar.gz>
  898.  
  899.   Both of these are fairly straight forward to install.
  900.  
  901.   6.5.  xlock
  902.  
  903.   If you install the shadow suite, and then run X Windows System and
  904.   lock the screen without upgrading your xlock, you will have to use
  905.   CNTL-ALT-Fx to switch to another tty, login, and kill the xlock
  906.   process (or use CNTL-ALT-BS to kill the X server).  Fortunately it's
  907.   fairly easy to upgrade your xlock program.
  908.  
  909.   If you are running XFree86 Versions 3.x.x, you are probably using
  910.   xlockmore (which is a great screen-saver in addition to a lock).  This
  911.   package supports shadow with a recompile.  If you have an older xlock,
  912.   I recommend that you upgrade to this one.
  913.  
  914.   xlockmore-3.5.tgz is available at:
  915.   <ftp://sunsite.unc.edu/pub/Linux/X11/xutils/screensavers/xlockmore-3.7.tgz>
  916.  
  917.   Basically, this is what you need to do:
  918.  
  919.   Get the xlockmore-3.7.tgz file and put it in /usr/src unpack it:
  920.  
  921.        tar -xzvf xlockmore-3.7.tgz
  922.  
  923.   Edit the file: /usr/X11R6/lib/X11/config/linux.cf, and change the
  924.   line:
  925.  
  926.        #define HasShadowPasswd    NO
  927.  
  928.        to
  929.  
  930.        #define HasShadowPasswd    YES
  931.  
  932.   Then build the executables:
  933.  
  934.        cd /usr/src/xlockmore
  935.        xmkmf
  936.        make depend
  937.        make
  938.  
  939.   Then move everything into place and update file ownerships and
  940.   permissions:
  941.  
  942.        cp xlock /usr/X11R6/bin/
  943.        cp XLock /var/X11R6/lib/app-defaults/
  944.        chown root.shadow /usr/X11R6/bin/xlock
  945.        chmod 2755 /usr/X11R6/bin/xlock
  946.        chown root.shadow /etc/shadow
  947.        chmod 640 /etc/shadow
  948.  
  949.   Your xlock will now work correctly.
  950.  
  951.   6.6.  xdm
  952.  
  953.   xdm is a program that presents a login screen for X-Windows.  Some
  954.   systems start xdm when the system is told to goto a specified run
  955.   level (see /etc/inittab.
  956.  
  957.   With the Shadow Suite install, xdm will need to be updated.
  958.   Fortunately it's fairly easy to upgrade your xdm program.
  959.  
  960.   xdm.tar.gz is available at:
  961.   <ftp://sunsite.unc.edu/pub/Linux/X11/xutils/xdm.tar.gz>
  962.  
  963.   Get the xdm.tar.gz file and put it in /usr/src, then to unpack it:
  964.  
  965.        tar -xzvf xdm.tar.gz
  966.  
  967.   Edit the file: /usr/X11R6/lib/X11/config/linux.cf, and change the
  968.   line:
  969.  
  970.        #define HasShadowPasswd    NO
  971.  
  972.        to
  973.  
  974.        #define HasShadowPasswd    YES
  975.  
  976.   Then build the executables:
  977.  
  978.        cd /usr/src/xdm
  979.        xmkmf
  980.        make depend
  981.        make
  982.  
  983.   Then move everything into place:
  984.  
  985.   cp xdm /usr/X11R6/bin/
  986.  
  987.   xdm is run as root so you don't need to change it file permissions.
  988.  
  989.   6.7.  sudo
  990.  
  991.   The program sudo allows a system administrator to let users run
  992.   programs that would normally require root access.  This is handy
  993.   because it lets the administrator limit access to the root account
  994.   itself while still allowing users to do things like mounting drives.
  995.  
  996.   sudo needs to read passwords because it verifies the users password
  997.   when it's invoked.  sudo already runs SUID root, so accessing the
  998.   /etc/shadow file is not a problem.
  999.  
  1000.   sudo for the shadow suite, is available as at:
  1001.   <ftp://sunsite.unc.edu/pub/Linux/system/Admin/sudo-1.2-shadow.tgz>
  1002.  
  1003.   Warning: When you install sudo your /etc/sudoers file will be replaced
  1004.   with a default one, so you need to make a backup of it if you have
  1005.   added anything to the default one.  (you could also edit the Makefile
  1006.   and remove the line that copies the default file to /etc).
  1007.  
  1008.   The package is already setup for shadow, so all that's required is to
  1009.   recompile the package (put it in /usr/src):
  1010.  
  1011.        cd /usr/src
  1012.        tar -xzvf sudo-1.2-shadow.tgz
  1013.        cd sudo-1.2-shadow
  1014.        make all
  1015.        make install
  1016.  
  1017.   6.8.  imapd (E-Mail pine package)
  1018.  
  1019.   imapd is an e-mail server similar to pop3d.  imapd comes with the Pine
  1020.   E-mail package.  The documentation that comes with the package states
  1021.   that the default for Linux systems is to include support for shadow.
  1022.   However, I have found that this is not true.  Furthermore, the build
  1023.   script / Makefile combination on this package is makes it very
  1024.   difficult to add the libshadow.a library at compile time, so I was
  1025.   unable to add shadow support for imapd.
  1026.  
  1027.   If anyone has this figured out, please E-mail me, and I'll include the
  1028.   solution here.
  1029.  
  1030.   6.9.  pppd (Point-to-Point Protocol Server)
  1031.  
  1032.   The pppd server can be setup to use several types of authentication:
  1033.   Password Authentication Protocol (PAP) and Cryptographic Handshake
  1034.   Authentication Protocol (CHAP).  The pppd server usually reads the
  1035.   password strings that it uses from /etc/ppp/chap-secrets and/or
  1036.   /etc/ppp/pap-secrets.  If you are using this default behavior of pppd,
  1037.   it is not necessary to reinstall pppd.
  1038.  
  1039.   pppd also allows you to use the login parameter (either on the command
  1040.   line, or in the configuration or options file).  If the login option
  1041.   is given, then pppd will use the /etc/passwd file for the username and
  1042.   passwords for the PAP.  This, of course, will no longer work now that
  1043.   our password file is shadowed.  For pppd-1.2.1d this requires adding
  1044.   code for shadow support.
  1045.  
  1046.   The example given in the next section is adding shadow support to
  1047.   pppd-1.2.1d (an older version of pppd).
  1048.  
  1049.   pppd-2.2.0 already contains shadow support.
  1050.  
  1051.   7.  Putting the Shadow Suite to use.
  1052.  
  1053.   This section discusses some of the things that you will want to know
  1054.   now that you have the Shadow Suite installed on your system.  More
  1055.   information is contained in the manual pages for each command.
  1056.  
  1057.   7.1.  Adding, Modifying, and deleting users
  1058.  
  1059.   The Shadow Suite added the following command line oriented commands
  1060.   for adding, modifying, and deleting users.  You may also have
  1061.   installed the adduser program.
  1062.  
  1063.   7.1.1.  useradd
  1064.  
  1065.   The useradd command can be used to add users to the system.  You also
  1066.   invoke this command to change the default settings.
  1067.  
  1068.   The first thing that you should do is to examine the default settings
  1069.   and make changes specific to your system:
  1070.  
  1071.        useradd -D
  1072.  
  1073.   ______________________________________________________________________
  1074.   GROUP=1
  1075.   HOME=/home
  1076.   INACTIVE=0
  1077.   EXPIRE=0
  1078.   SHELL=
  1079.   SKEL=/etc/skel
  1080.   ______________________________________________________________________
  1081.  
  1082.   The defaults are probably not what you want, so if you started adding
  1083.   users now you would have to specify all the information for each user.
  1084.   However, we can and should change the default values.
  1085.  
  1086.   On my system:
  1087.  
  1088.   ╖  I want the default group to be 100
  1089.  
  1090.   ╖  I want passwords to expire every 60 days
  1091.  
  1092.   ╖  I don't want to lock an account because the password is expired
  1093.  
  1094.   ╖  I want to default shell to be /bin/bash
  1095.  
  1096.      To make these changes I would use:
  1097.  
  1098.        useradd -D -g100 -e60 -f0 -s/bin/bash
  1099.  
  1100.   Now running useradd -D will give:
  1101.  
  1102.   ______________________________________________________________________
  1103.   GROUP=100
  1104.   HOME=/home
  1105.   INACTIVE=0
  1106.   EXPIRE=60
  1107.   SHELL=/bin/bash
  1108.   SKEL=/etc/skel
  1109.   ______________________________________________________________________
  1110.  
  1111.   Just in case you wanted to know, these defaults are stored in the file
  1112.   /etc/default/useradd.
  1113.  
  1114.   Now you can use useradd to add users to the system.  For example, to
  1115.   add the user fred, using the defaults, you would use the following:
  1116.  
  1117.        useradd -m -c "Fred Flintstone" fred
  1118.  
  1119.   This will create the following entry in the /etc/passwd file:
  1120.  
  1121.        fred:*:505:100:Fred Flintstone:/home/fred:/bin/bash
  1122.  
  1123.   And the following entry in the /etc/shadow file:
  1124.  
  1125.        fred:!:0:0:60:0:0:0:0
  1126.  
  1127.   fred's home directory will be created and the contents of /etc/skel
  1128.   will be copied there because of the -m switch.
  1129.  
  1130.   Also, since we did not specify a UID, the next available one was used.
  1131.  
  1132.   fred's account is created, but fred still won't be able to login until
  1133.   we unlock the account.  We do this by changing the password.
  1134.  
  1135.        passwd fred
  1136.  
  1137.   ______________________________________________________________________
  1138.   Changing password for fred
  1139.   Enter the new password (minimum of 5 characters)
  1140.   Please use a combination of upper and lower case letters and numbers.
  1141.   New Password: *******
  1142.   Re-enter new password: *******
  1143.   ______________________________________________________________________
  1144.  
  1145.   Now the /etc/shadow will contain:
  1146.  
  1147.        fred:J0C.WDR1amIt6:9559:0:60:0:0:0:0
  1148.  
  1149.   And fred will now be able to login and use the system.  The nice thing
  1150.   about useradd and the other programs that come with the Shadow Suite
  1151.   is that they make changes to the /etc/passwd and /etc/shadow files
  1152.   atomically.  So if you are adding a user, and another user is changing
  1153.   their password at the same time, both operations will be performed
  1154.   correctly.
  1155.  
  1156.   You should use the supplied commands rather than directly editing
  1157.   /etc/passwd and /etc/shadow.  If you were editing the /etc/shadow
  1158.   file, and a user were to change his password while you are editing,
  1159.   and then you were to save the file you were editing, the user's
  1160.   password change would be lost.
  1161.  
  1162.   Here is a small interactive script that adds users using useradd and
  1163.   passwd:
  1164.  
  1165.   ______________________________________________________________________
  1166.   #!/bin/bash
  1167.   #
  1168.   # /sbin/newuser - A script to add users to the system using the Shadow
  1169.   #                 Suite's useradd and passwd commands.
  1170.   #
  1171.   # Written my Mike Jackson <mhjack@tscnet.com> as an example for the Linux
  1172.   # Shadow Password Howto.  Permission to use and modify is expressly granted.
  1173.   #
  1174.   # This could be modified to show the defaults and allow modification similar
  1175.   # to the Slackware Adduser program.  It could also be modified to disallow
  1176.   # stupid entries.  (i.e. better error checking).
  1177.   #
  1178.   ##
  1179.   #  Defaults for the useradd command
  1180.   ##
  1181.   GROUP=100        # Default Group
  1182.   HOME=/home       # Home directory location (/home/username)
  1183.   SKEL=/etc/skel   # Skeleton Directory
  1184.   INACTIVE=0       # Days after password expires to disable account (0=never)
  1185.   EXPIRE=60        # Days that a passwords lasts
  1186.   SHELL=/bin/bash  # Default Shell (full path)
  1187.   ##
  1188.   #  Defaults for the passwd command
  1189.   ##
  1190.   PASSMIN=0        # Days between password changes
  1191.   PASSWARN=14      # Days before password expires that a warning is given
  1192.   ##
  1193.   #  Ensure that root is running the script.
  1194.   ##
  1195.   WHOAMI=`/usr/bin/whoami`
  1196.   if [ $WHOAMI != "root" ]; then
  1197.           echo "You must be root to add news users!"
  1198.           exit 1
  1199.   fi
  1200.   ##
  1201.   #  Ask for username and fullname.
  1202.   ##
  1203.   echo ""
  1204.   echo -n "Username: "
  1205.   read USERNAME
  1206.   echo -n "Full name: "
  1207.   read FULLNAME
  1208.   #
  1209.   echo "Adding user: $USERNAME."
  1210.   #
  1211.   # Note that the "" around $FULLNAME is required because this field is
  1212.   # almost always going to contain at least on space, and without the "'s
  1213.   # the useradd command would think that you we moving on to the next
  1214.   # parameter when it reached the SPACE character.
  1215.   #
  1216.   /usr/sbin/useradd -c"$FULLNAME" -d$HOME/$USERNAME -e$EXPIRE \
  1217.           -f$INACTIVE -g$GROUP -m -k$SKEL -s$SHELL $USERNAME
  1218.   ##
  1219.   #  Set password defaults
  1220.   ##
  1221.   /bin/passwd -n $PASSMIN -w $PASSWARN $USERNAME >/dev/null 2>&1
  1222.   ##
  1223.   #  Let the passwd command actually ask for password (twice)
  1224.   ##
  1225.   /bin/passwd $USERNAME
  1226.   ##
  1227.   #  Show what was done.
  1228.   ##
  1229.   echo ""
  1230.   echo "Entry from /etc/passwd:"
  1231.   echo -n "   "
  1232.   grep "$USERNAME:" /etc/passwd
  1233.   echo "Entry from /etc/shadow:"
  1234.   echo -n "   "
  1235.   grep "$USERNAME:" /etc/shadow
  1236.   echo "Summary output of the passwd command:"
  1237.   echo -n "   "
  1238.   passwd -S $USERNAME
  1239.   echo ""
  1240.   ______________________________________________________________________
  1241.  
  1242.   Using a script to add new users is really much more preferable than
  1243.   editing the /etc/passwd or /etc/shadow files directly or using a
  1244.   program like the Slackware adduser program.  Feel free to use and
  1245.   modify this script for your particular system.
  1246.  
  1247.   For more information on the useradd see the online manual page.
  1248.  
  1249.   7.1.2.  usermod
  1250.  
  1251.   The usermod program is used to modify the information on a user.  The
  1252.   switches are similar to the useradd program.
  1253.  
  1254.   Let's say that you want to change fred's shell, you would do the
  1255.   following:
  1256.  
  1257.        usermod -s /bin/tcsh fred
  1258.  
  1259.   Now fred's /etc/passwd file entry would be change to this:
  1260.  
  1261.        fred:*:505:100:Fred Flintstone:/home/fred:/bin/tcsh
  1262.  
  1263.   Let's make fred's account expire on 09/15/97:
  1264.  
  1265.        usermod -e 09/15/97 fred
  1266.  
  1267.   Now fred's entry in /etc/shadow becomes:
  1268.  
  1269.        fred:J0C.WDR1amIt6:9559:0:60:0:0:10119:0
  1270.  
  1271.   For more information on the usermod command see the online manual
  1272.   page.
  1273.  
  1274.   7.1.3.  userdel
  1275.  
  1276.   userdel does just what you would expect, it deletes the user's
  1277.   account.  You simply use:
  1278.  
  1279.        userdel -r username
  1280.  
  1281.   The -r causes all files in the user's home directory to be removed
  1282.   along with the home directory itself.  Files located in other file
  1283.   system will have to be searched for and deleted manually.
  1284.  
  1285.   If you want to simply lock the account rather than delete it, use the
  1286.   passwd command instead.
  1287.  
  1288.   7.2.  The passwd command and passwd aging.
  1289.  
  1290.   The passwd command has the obvious use of changing passwords.
  1291.   Additionally, it is used by the root user to:
  1292.  
  1293.   ╖  Lock and unlock accounts (-l and -u)
  1294.  
  1295.   ╖  Set the maximum number of days that a password remains valid (-x)
  1296.  
  1297.   ╖  Set the minimum days between password changes (-n)
  1298.  
  1299.   ╖  Sets the number of days of warning that a password is about to
  1300.      expire (-w)
  1301.  
  1302.   ╖  Sets the number of days after the password expires before the
  1303.      account is locked (-i)
  1304.  
  1305.   ╖  Allow viewing of account information in a clearer format (-S)
  1306.  
  1307.   For example, let look again at fred
  1308.  
  1309.        passwd -S fred
  1310.        fred P 03/04/96 0 60 0 0
  1311.  
  1312.   This means that fred's password is valid, it was last changed on
  1313.   03/04/96, it can be changed at any time, it expires after 60 days,
  1314.   fred will not be warned, and and the account won't be disabled when
  1315.   the password expires.
  1316.  
  1317.   This simply means that if fred logs in after the password expires, he
  1318.   will be prompted for a new password at login.
  1319.  
  1320.   If we decide that we want to warn fred 14 days before his password
  1321.   expires and make his account inactive 14 days after he lets it expire,
  1322.   we would need to do the following:
  1323.  
  1324.        passwd -w14 -i14 fred
  1325.  
  1326.   Now fred is changed to:
  1327.        fred P 03/04/96 0 60 14 14
  1328.  
  1329.   For more information on the passwd command see the online manual page.
  1330.  
  1331.   7.3.  The login.defs file.
  1332.  
  1333.   The file /etc/login is the configuration file for the login program
  1334.   and also for the Shadow Suite as a whole.
  1335.  
  1336.   /etc/login contains settings from what the prompts will look like to
  1337.   what the default expiration will be when a user changes his password.
  1338.  
  1339.   The /etc/login.defs file is quite well documented just by the comments
  1340.   that are contained within it.  However, there are a few things to
  1341.   note:
  1342.  
  1343.   ╖  It contains flags that can be turned on or off that determine the
  1344.      amount of logging that takes place.
  1345.  
  1346.   ╖  It contains pointers to other configuration files.
  1347.  
  1348.   ╖  It contains defaults assignments for things like password aging.
  1349.  
  1350.   From the above list you can see that this is a rather important file,
  1351.   and you should make sure that it is present, and that the settings are
  1352.   what you desire for your system.
  1353.  
  1354.   7.4.  Group passwords.
  1355.  
  1356.   The /etc/groups file may contain passwords that permit a user to
  1357.   become a member of a particular group.  This function is enabled if
  1358.   you define the constant SHADOWGRP in the /usr/src/shadow-
  1359.   YYMMDD/config.h file.
  1360.  
  1361.   If you define this constant and then compile, you must create an
  1362.   /etc/gshadow file to hold the group passwords and the group
  1363.   administrator information.
  1364.  
  1365.   When you created the /etc/shadow, you used a program called pwconv,
  1366.   there no equivalent program to create the /etc/gshadow file, but it
  1367.   really doesn't matter, it takes care of itself.
  1368.  
  1369.   To create the initial /etc/gshadow file do the following:
  1370.  
  1371.        touch /etc/gshadow
  1372.        chown root.root /etc/gshadow
  1373.        chmod 700 /etc/gshadow
  1374.  
  1375.   Once you create new groups, they will be added to the /etc/group and
  1376.   the /etc/gshadow files.  If you modify a group by adding or removing
  1377.   users or changing the group password, the /etc/gshadow file will be
  1378.   changed.
  1379.  
  1380.   The programs groups, groupadd, groupmod, and groupdel are provided as
  1381.   part of the Shadow Suite to modify groups.
  1382.  
  1383.   The format of the /etc/group file is as follows:
  1384.  
  1385.        groupname:!:GID:member,member,...
  1386.  
  1387.   Where:
  1388.  
  1389.      groupname
  1390.         The name of the group
  1391.  
  1392.      !  The field that normally holds the password, but that is now
  1393.         relocated to the /etc/gshadow file.
  1394.  
  1395.      GID
  1396.         The numerical group ID number
  1397.  
  1398.      member
  1399.         List of group members
  1400.  
  1401.   The format of the /etc/gshadow file is as follows:
  1402.  
  1403.        groupname:password:admin,admin,...:member,member,...
  1404.  
  1405.   Where:
  1406.  
  1407.      groupname
  1408.         The name of the group
  1409.  
  1410.      password
  1411.         The encoded group password.
  1412.  
  1413.      admin
  1414.         List of group administrators
  1415.  
  1416.      member
  1417.         List of group members
  1418.  
  1419.   The command gpasswd is used only for adding or removing administrators
  1420.   and members to or from a group.  root or someone in the list of
  1421.   administrators may add or remove group members.
  1422.  
  1423.   The groups password can be changed using the passwd command by root or
  1424.   anyone listed as an administrator for the group.
  1425.  
  1426.   Despite the fact that there is not currently a manual page for
  1427.   gpasswd, typing gpasswd without any parameters gives a listing of
  1428.   options.  It's fairly easy to grasp how it all works once you
  1429.   understand the file formats and the concepts.
  1430.  
  1431.   7.5.  Consistency checking programs
  1432.  
  1433.   7.5.1.  pwck
  1434.  
  1435.   The program pwck is provided to provide a consistency check on the
  1436.   /etc/passwd and /etc/shadow files.  It will check each username and
  1437.   verify that it has the following:
  1438.  
  1439.   ╖  the correct number of fields
  1440.  
  1441.   ╖  unique user name
  1442.  
  1443.   ╖  valid user and group identifier
  1444.  
  1445.   ╖  valid primary group
  1446.  
  1447.   ╖  valid home directory
  1448.  
  1449.   ╖  valid login shell
  1450.  
  1451.   It will also warn of any account that has no password.
  1452.  
  1453.   It's a good idea to run pwck after installing the Shadow Suite.  It's
  1454.   also a good idea to run it periodically, perhaps weekly or monthly.
  1455.   If you use the -r option, you can use cron to run it on a regular
  1456.   basis and have the report mailed to you.
  1457.  
  1458.   7.5.2.  grpck
  1459.  
  1460.   grpck is the consistency checking program for the /etc/group and
  1461.   /etc/gshadow files.  It performs the following checks:
  1462.  
  1463.   ╖  the correct number of fields
  1464.  
  1465.   ╖  unique group name
  1466.  
  1467.   ╖  valid list of members and administrators
  1468.  
  1469.   It also has the -r option for automated reports.
  1470.  
  1471.   7.6.  Dial-up passwords.
  1472.  
  1473.   Dial-up passwords are another optional line of defense for systems
  1474.   that allow dial-in access.  If you have a system that allows many
  1475.   people to connect locally or via a network, but you want to limit who
  1476.   can dial in and connect, then dial-up passwords are for you.  To
  1477.   enable dial-up passwords, you must edit the file /etc/login.defs and
  1478.   ensure that DIALUPS_CHECK_ENAB is set to yes.
  1479.  
  1480.   Two files contain the dial-up information, /etc/dialups which contains
  1481.   the ttys (one per line, with the leading "/dev/" removed).  If a tty
  1482.   is listed then dial-up checks are performed.
  1483.  
  1484.   The second file is the /etc/d_passwd file.  This file contains the
  1485.   fully qualified path name of a shell, followed by an optional
  1486.   password.
  1487.  
  1488.   If a user logs into a line that is listed in /etc/dialups, and his
  1489.   shell is listed in the file /etc/d_passwd he will be allowed access
  1490.   only by suppling the correct password.
  1491.  
  1492.   Another useful purpose for using dial-up passwords might be to setup a
  1493.   line that only allows a certain type of connect (perhaps a PPP or UUCP
  1494.   connection).  If a user tries to get another type of connection (i.e.
  1495.   a list of shells), he must know a password to use the line.
  1496.  
  1497.   Before you can use the dial-up feature, you must create the files.
  1498.  
  1499.   The command dpasswd is provided to assign passwords to the shells in
  1500.   the /etc/d_passwd file.  See the manual page for more information.
  1501.   8.  Adding shadow support to a C program
  1502.  
  1503.   Adding shadow support to a program is actually fairly straightforward.
  1504.   The only problem is that the program must be run by root (or SUID
  1505.   root) in order for the the program to be able to access the
  1506.   /etc/shadow file.
  1507.  
  1508.   This presents one big problem: very careful programming practices must
  1509.   be followed when creating SUID programs.  For instance, if a program
  1510.   has a shell escape, this must not occur as root if the program is SUID
  1511.   root.
  1512.  
  1513.   For adding shadow support to a program so that it can check passwords,
  1514.   but otherwise does need to run as root, it's a lot safer to run the
  1515.   program SUID shadow instead.  The xlock program is an example of this.
  1516.  
  1517.   In the example given below, pppd-1.2.1d already runs SUID as root, so
  1518.   adding shadow support should not make the program any more vulnerable.
  1519.  
  1520.   8.1.  Header files
  1521.  
  1522.   The header files should reside in /usr/include/shadow.  There should
  1523.   also be a /usr/include/shadow.h, but it will be a symbolic link to
  1524.   /usr/include/shadow/shadow.h.
  1525.  
  1526.   To add shadow support to a program, you need to include the header
  1527.   files:
  1528.  
  1529.   #include <shadow/shadow.h>
  1530.   #include <shadow/pwauth.h>
  1531.  
  1532.   It might be a good idea to use compiler directives to conditionally
  1533.   compile the shadow code (I do in the example below).
  1534.  
  1535.   8.2.  libshadow.a library
  1536.  
  1537.   When you installed the Shadow Suite the libshadow.a file was created
  1538.   and installed in /usr/lib.
  1539.  
  1540.   When compiling shadow support into a program, the linker needs to be
  1541.   told to include the libshadow.a library into the link.
  1542.  
  1543.   This is done by:
  1544.  
  1545.        gcc program.c -o program -lshadow
  1546.  
  1547.   However, as we will see in the example below, most large programs use
  1548.   a Makefile, and usually have a variable called LIBS=... that we will
  1549.   modify.
  1550.  
  1551.   8.3.  Shadow Structure
  1552.  
  1553.   The libshadow.a library uses a structure called spwd for the
  1554.   information it retrieves from the /etc/shadow file.  This is the
  1555.   definition of the spwd structure from the /usr/include/shadow/shadow.h
  1556.   header file:
  1557.  
  1558.   ______________________________________________________________________
  1559.   struct spwd
  1560.   {
  1561.     char *sp_namp;                /* login name */
  1562.     char *sp_pwdp;                /* encrypted password */
  1563.     sptime sp_lstchg;             /* date of last change */
  1564.     sptime sp_min;                /* minimum number of days between changes */
  1565.     sptime sp_max;                /* maximum number of days between changes */
  1566.     sptime sp_warn;               /* number of days of warning before password
  1567.                                      expires */
  1568.     sptime sp_inact;              /* number of days after password expires
  1569.                                      until the account becomes unusable. */
  1570.     sptime sp_expire;             /* days since 1/1/70 until account expires
  1571.   */
  1572.     unsigned long sp_flag;        /* reserved for future use */
  1573.   };
  1574.   ______________________________________________________________________
  1575.  
  1576.   The Shadow Suite can put things into the sp_pwdp field besides just
  1577.   the encoded passwd.  The password field could contain:
  1578.  
  1579.        username:Npge08pfz4wuk;@/sbin/extra:9479:0:10000::::
  1580.  
  1581.   This means that in addition to the password, the program /sbin/extra
  1582.   should be called for further authentication.  The program called will
  1583.   get passed the username and a switch that indicates why it's being
  1584.   called.  See the file /usr/include/shadow/pwauth.h and the source code
  1585.   for pwauth.c for more information.
  1586.  
  1587.   What this means is that we should use the function pwauth to perform
  1588.   the actual authentication, as it will take care of the secondary
  1589.   authentication as well.  The example below does this.
  1590.  
  1591.   The author of the Shadow Suite indicates that since most programs in
  1592.   existence don't do this, and that it may be removed or changed in
  1593.   future versions of the Shadow Suite.
  1594.  
  1595.   8.4.  Shadow Functions
  1596.  
  1597.   The shadow.h file also contains the function prototypes for the
  1598.   functions contained in the libshadow.a library:
  1599.  
  1600.   ______________________________________________________________________
  1601.   extern void setspent __P ((void));
  1602.   extern void endspent __P ((void));
  1603.   extern struct spwd *sgetspent __P ((__const char *__string));
  1604.   extern struct spwd *fgetspent __P ((FILE *__fp));
  1605.   extern struct spwd *getspent __P ((void));
  1606.   extern struct spwd *getspnam __P ((__const char *__name));
  1607.   extern int putspent __P ((__const struct spwd *__sp, FILE *__fp));
  1608.   ______________________________________________________________________
  1609.  
  1610.   The function that we are going to use in the example is: getspnam
  1611.   which will retrieve for us a spwd structure for the supplied name.
  1612.  
  1613.   8.5.  Example
  1614.  
  1615.   This is an example of adding shadow support to a program that needs
  1616.   it, but does not have it by default.
  1617.  
  1618.   This example uses the Point-to-Point Protocol Server (pppd-1.2.1d),
  1619.   which has a mode in which it performs PAP authentication using user
  1620.   names and passwords from the /etc/passwd file instead of the PAP or
  1621.   CHAP files.  You would not need to add this code to pppd-2.2.0 because
  1622.   it's already there.
  1623.  
  1624.   This feature of pppd probably isn't used very much, but if you
  1625.   installed the Shadow Suite, it won't work anymore because the
  1626.   passwords are no longer stored in /etc/passwd.
  1627.  
  1628.   The code for authenticating users under pppd-1.2.1d is located in the
  1629.   /usr/src/pppd-1.2.1d/pppd/auth.c file.
  1630.  
  1631.   The following code needs to be added to the top of the file where all
  1632.   the other #include directives are.  We have surrounded the #includes
  1633.   with conditional directives (i.e. only include if we are compiling for
  1634.   shadow support).
  1635.  
  1636.   ______________________________________________________________________
  1637.   #ifdef HAS_SHADOW
  1638.   #include <shadow.h>
  1639.   #include <shadow/pwauth.h>
  1640.   #endif
  1641.   ______________________________________________________________________
  1642.  
  1643.   The next thing to do is to modify the actual code.  We are still
  1644.   making changes to the auth.c file.
  1645.  
  1646.   Function auth.c before modifications:
  1647.  
  1648.   ______________________________________________________________________
  1649.   /*
  1650.    * login - Check the user name and password against the system
  1651.    * password database, and login the user if OK.
  1652.    *
  1653.    * returns:
  1654.    *      UPAP_AUTHNAK: Login failed.
  1655.    *      UPAP_AUTHACK: Login succeeded.
  1656.    * In either case, msg points to an appropriate message.
  1657.    */
  1658.   static int
  1659.   login(user, passwd, msg, msglen)
  1660.       char *user;
  1661.       char *passwd;
  1662.       char **msg;
  1663.       int *msglen;
  1664.   {
  1665.       struct passwd *pw;
  1666.       char *epasswd;
  1667.       char *tty;
  1668.  
  1669.       if ((pw = getpwnam(user)) == NULL) {
  1670.           return (UPAP_AUTHNAK);
  1671.       }
  1672.        /*
  1673.        * XXX If no passwd, let them login without one.
  1674.        */
  1675.       if (pw->pw_passwd == '\0') {
  1676.           return (UPAP_AUTHACK);
  1677.       }
  1678.  
  1679.       epasswd = crypt(passwd, pw->pw_passwd);
  1680.       if (strcmp(epasswd, pw->pw_passwd)) {
  1681.           return (UPAP_AUTHNAK);
  1682.       }
  1683.  
  1684.       syslog(LOG_INFO, "user %s logged in", user);
  1685.  
  1686.       /*
  1687.        * Write a wtmp entry for this user.
  1688.        */
  1689.       tty = strrchr(devname, '/');
  1690.       if (tty == NULL)
  1691.           tty = devname;
  1692.       else
  1693.           tty++;
  1694.       logwtmp(tty, user, "");             /* Add wtmp login entry */
  1695.       logged_in = TRUE;
  1696.  
  1697.       return (UPAP_AUTHACK);
  1698.   }
  1699.   ______________________________________________________________________
  1700.  
  1701.   The user's password is placed into pw->pw_passwd, so all we really
  1702.   need to do is add the function getspnam.  This will put the password
  1703.   into spwd->sp_pwdp.
  1704.  
  1705.   We will add the function pwauth to perform the actual authentication.
  1706.   This will automatically perform secondary authentication if the shadow
  1707.   file is setup for it.
  1708.  
  1709.   Function auth.c after modifications to support shadow:
  1710.  
  1711.   ______________________________________________________________________
  1712.   /*
  1713.    * login - Check the user name and password against the system
  1714.    * password database, and login the user if OK.
  1715.    *
  1716.    * This function has been modified to support the Linux Shadow Password
  1717.    * Suite if USE_SHADOW is defined.
  1718.    *
  1719.    * returns:
  1720.    *      UPAP_AUTHNAK: Login failed.
  1721.    *      UPAP_AUTHACK: Login succeeded.
  1722.    * In either case, msg points to an appropriate message.
  1723.    */
  1724.   static int
  1725.   login(user, passwd, msg, msglen)
  1726.       char *user;
  1727.       char *passwd;
  1728.       char **msg;
  1729.       int *msglen;
  1730.   {
  1731.       struct passwd *pw;
  1732.       char *epasswd;
  1733.       char *tty;
  1734.  
  1735.   #ifdef USE_SHADOW
  1736.       struct spwd *spwd;
  1737.       struct spwd *getspnam();
  1738.   #endif
  1739.  
  1740.       if ((pw = getpwnam(user)) == NULL) {
  1741.           return (UPAP_AUTHNAK);
  1742.       }
  1743.  
  1744.   #ifdef USE_SHADOW
  1745.           spwd = getspnam(user);
  1746.           if (spwd)
  1747.                   pw->pw_passwd = spwd->sp-pwdp;
  1748.   #endif
  1749.  
  1750.        /*
  1751.        * XXX If no passwd, let NOT them login without one.
  1752.        */
  1753.       if (pw->pw_passwd == '\0') {
  1754.           return (UPAP_AUTHNAK);
  1755.       }
  1756.   #ifdef HAS_SHADOW
  1757.       if ((pw->pw_passwd && pw->pw_passwd[0] == '@'
  1758.            && pw_auth (pw->pw_passwd+1, pw->pw_name, PW_LOGIN, NULL))
  1759.           || !valid (passwd, pw)) {
  1760.           return (UPAP_AUTHNAK);
  1761.       }
  1762.   #else
  1763.       epasswd = crypt(passwd, pw->pw_passwd);
  1764.       if (strcmp(epasswd, pw->pw_passwd)) {
  1765.           return (UPAP_AUTHNAK);
  1766.       }
  1767.   #endif
  1768.  
  1769.       syslog(LOG_INFO, "user %s logged in", user);
  1770.  
  1771.       /*
  1772.        * Write a wtmp entry for this user.
  1773.        */
  1774.       tty = strrchr(devname, '/');
  1775.       if (tty == NULL)
  1776.           tty = devname;
  1777.       else
  1778.           tty++;
  1779.       logwtmp(tty, user, "");             /* Add wtmp login entry */
  1780.       logged_in = TRUE;
  1781.  
  1782.       return (UPAP_AUTHACK);
  1783.   }
  1784.   ______________________________________________________________________
  1785.  
  1786.   Careful examination will reveal that we made another change as well.
  1787.   The original version allowed access (returned UPAP_AUTHACK if there
  1788.   was NO password in the /etc/passwd file.  This is not good, because a
  1789.   common use of this login feature is to use one account to allow access
  1790.   to the PPP process and then check the username and password supplied
  1791.   by PAP with the username in the /etc/passwd file and the password in
  1792.   the /etc/shadow file.
  1793.  
  1794.   So if we had set the original version up to run as the shell for a
  1795.   user i.e.  ppp, then anyone could get a ppp connection by setting
  1796.   their PAP to user ppp and a password of null.
  1797.  
  1798.   We fixed this also by returning UPAP_AUTHNAK instead of UPAP_AUTHACK
  1799.   if the password field was empty.
  1800.  
  1801.   Interestingly enough, pppd-2.2.0 has the same problem.
  1802.  
  1803.   Next we need to modify the Makefile so that two things occur:
  1804.   USE_SHADOW must be defined, and libshadow.a needs to be added to the
  1805.   linking process.
  1806.  
  1807.   Edit the Makefile, and add:
  1808.  
  1809.        LIBS = -lshadow
  1810.  
  1811.   Then we find the line:
  1812.  
  1813.        COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t
  1814.  
  1815.   And change it to:
  1816.  
  1817.        COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t -DUSE_SHADOW
  1818.  
  1819.   Now make and install.
  1820.  
  1821.   9.  Frequently Asked Questions.
  1822.  
  1823.   Q: I used to control which tty's root could log into using the file
  1824.   /etc/securettys, but it doesn't seem to work anymore, what's going on?
  1825.  
  1826.   A: The file /etc/securettys does absolutely nothing now that the
  1827.   Shadow Suite is installed.  The tty's that root can use are now
  1828.   located in the login configuration file /etc/login.defs.  The entry in
  1829.   this file may point to another file.
  1830.  
  1831.   Q: I installed the Shadow Suite, but now I can't login, what did I
  1832.   miss?
  1833.  
  1834.   A: You probably installed the Shadow programs, but didn't run pwconv
  1835.   or you forgot to copy /etc/npasswd to /etc/passwd and /etc/nshadow to
  1836.   /etc/shadow.  Also, you may need to copy login.defs to /etc.
  1837.  
  1838.   Q: In the section on xlock, it said to change the group ownership of
  1839.   the /etc/shadow file to shadow.  I don't have a shadow group, what do
  1840.   I do?
  1841.  
  1842.   A: You can add one.  Simply edit the /etc/group file, and insert a
  1843.   line for the shadow group.  You need to ensure that the group number
  1844.   is not used by another group, and you need to insert it before the
  1845.   nogroup entry.  Or you can simply suid xlock to root.
  1846.  
  1847.   Q: Is there a mailing list for the Linux Shadow Password Suite?
  1848.  
  1849.   A: Yes, but it's for the development and beta testing of the next
  1850.   Shadow Suite for Linux.  You can get added to the list by mailing to:
  1851.   shadow-list-request@neptune.cin.net with a subject of: subscribe.  The
  1852.   list is actually for discussions of the Linux shadow-YYMMSS series of
  1853.   releases.  You should join if you want to get involved in further
  1854.   development or if you install the Suite on your system and want to get
  1855.   information on newer releases.
  1856.  
  1857.   Q: I installed the Shadow Suite, but when I use the userdel command, I
  1858.   get "userdel: cannot open shadow group file", what did I do wrong?
  1859.  
  1860.   A: You compiled the Shadow Suite with the SHADOWGRP option enabled,
  1861.   but you don't have an /etc/gshadow file.  You need to either edit the
  1862.   config.h file and recompile, or create an /etc/group file.  See the
  1863.   section on shadow groups.
  1864.  
  1865.   Q: I installed the Shadow Suite but now I'm getting encoded passwords
  1866.   back in my /etc/passwd file, what's wrong?
  1867.  
  1868.   A: You either enabled the AUTOSHADOW option in the Shadow config.h
  1869.   file, or your libc was compiled with the SAHDOW_COMPAT option.  You
  1870.   need to determine which is the problem, and recompile.
  1871.  
  1872.   10.  Copyright Message.
  1873.  
  1874.   The Linux Shadow Password HOWTO is Copyright (c) 1996 Michael H.
  1875.   Jackson.
  1876.  
  1877.   Permission is granted to make and distribute verbatim copies of this
  1878.   document provided the copyright notice and this permission notice are
  1879.   preserved on all copies.
  1880.  
  1881.   Permission is granted to copy and distribute modified versions of this
  1882.   document under the conditions for verbatim copies above, provided a
  1883.   notice clearly stating that the document is a modified version is also
  1884.   included in the modified document.
  1885.  
  1886.   Permission is granted to copy and distribute translations of this
  1887.   document into another language, under the conditions specified above
  1888.   for modified versions.
  1889.  
  1890.   Permission is granted to convert this document into another media
  1891.   under the conditions specified above for modified versions provided
  1892.   the requirement to acknowledge the source document is fulfilled by
  1893.   inclusion of an obvious reference to the source document in the new
  1894.   media. Where there is any doubt as to what defines 'obvious' the
  1895.   copyright owner reserves the right to decide.
  1896.  
  1897.   11.  Miscellaneous and Acknowledgments.
  1898.  
  1899.   The code examples for auth.c are taken from pppd-1.2.1d and
  1900.   ppp-2.1.0e, Copyright (c) 1993 and The Australian National University
  1901.   and Copyright (c) 1989 Carnegie Mellon University.
  1902.  
  1903.   Thanks to Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> for
  1904.   writing and maintaining the Shadow Suite for Linux, and for his review
  1905.   and comments on this document.
  1906.  
  1907.   Thanks to Ron Tidd <rtidd@tscnet.com> for his helpful review and
  1908.   testing.
  1909.  
  1910.   Thanks to everyone who has sent me feedback to help improve this
  1911.   document.
  1912.  
  1913.   Please, if you have any comments or suggestions then mail them to me.
  1914.  
  1915.   regards
  1916.  
  1917.   Michael H. Jackson <mhjack@tscnet.com>
  1918.  
  1919.